HIPAA PHI: List of 18 Identifiers and Definition of PHI

List of 18 Identifiers

1. Names;
2. All geographical subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code, if according to the current publicly available data from the Bureau of the Census: (1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and (2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.
3. All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
4. Phone numbers;
5. Fax numbers;
6. Electronic mail addresses;
7. Social Security numbers;
8. Medical record numbers;
9. Health plan beneficiary numbers;
10. Account numbers;
11. Certificate/license numbers;
12. Vehicle identifiers and serial numbers, including license plate numbers;
13. Device identifiers and serial numbers;
14. Web Universal Resource Locators (URLs);
15. Internet Protocol (IP) address numbers;
16. Biometric identifiers, including finger and voice prints;
17. Full face photographic images and any comparable images; and
18. Any other unique identifying number, characteristic, or code (note this does not mean the unique code assigned by the investigator to code the data)

There are also additional standards and criteria to protect individual's privacy from re-identification. Any code used to replace the identifiers in datasets cannot be derived from any information related to the individual and the master codes, nor can the method to derive the codes be disclosed. For example, a subject's initials cannot be used to code their data because the initials are derived from their name. Additionally, the researcher must not have actual knowledge that the research subject could be re-identified from the remaining identifiers in the PHI used in the research study. In other words, the information would still be considered identifiable is there was a way to identify the individual even though all of the 18 identifiers were removed.

Definition

What is PHI?

Protected health information (PHI) is any information in the medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment. HIPAA regulations allow researchers to access and use PHI when necessary to conduct research. However, HIPAA only affects research that uses, creates, or discloses PHI that will be entered in to the medical record or will be used for healthcare services, such as treatment, payment or operations.

For example, PHI is used in research studies involving review of existing medical records for research information, such as retrospective chart review. Also, studies that create new medical information because a health care service is being performed as part of research, such as diagnosing a health condition or a new drug or device for treating a health condition, create PHI that will be entered into the medical record. For example, sponsored clinical trails that submit data to the U.S. Food and Drug Administration involve PHI and are therefore subject to HIPAA regulations.

What is not PHI?

In contrast, some research studies use data that is person-identifiable because it includes personal identifiers such as name, address, but it is not considered to be PHI because the data are not associated with or derived from a healthcare service event (treatment, payment, operations, medical records) not entered into the medical records, nor will the subject/patient be informed of the results. Research health information that is kept only in the researcher’s records is not subject to HIPAA but is regulated by other human subjects protection regulations.

Examples of research health information not subject to HIPAA include such studies as the use of aggregate data, diagnostic tests that do not go into the medical record because they are part of a basic research study and the results will not be disclosed to the subject, and testing done without the PHI identifiers. Some genetic basic research can fall into this category such as the search for potential genetic markers, promoter control elements, and other exploratory genetic research. In contrast, genetic testing for a known disease that is considered to be part of diagnosis, treatment and health care would be considered to use PHI and therefore subject to HIPAA regulations.

Also note, health information by itself without the 18 identifiers is not considered to be PHI. For example, a dataset of vital signs by themselves do not constitute protected health information. However, if the vital signs dataset includes medical record numbers, then the entire dataset must be protected since it contains an identifier. PHI is anything that can be used to identify an individual such as private information, facial images, fingerprints, and voiceprints. These can be associated with medical records, biological specimens, biometrics, data sets, as well as direct identifiers of the research subjects in clinical trials.

Read More»

Basic concept for capacity building

Research ethics committees review proposed studies with human participants to ensure that they conform to internationally and locally accepted ethical guidelines, monitor studies once they have begun and, where relevant,take part in follow-up action and surveillance after the end of the research. Committees have the authority to approve, reject or stop studies or require modifi cations to research protocols. They may also perform other functions, such as setting policies or off ering opinions on ongoing ethical issues in research.

Read More»

How to Write a Standard Operating Procedure? SOP

A Standard Operating Procedure (SOP) is a document consisting of step-by-step information on how to execute a task. An existing SOP may need to just be modified and updated, or you may be in a scenario where you have to write one from scratch. It sounds daunting, but it’s really just a very, very, very thorough checklist. 

Part 1 of 3: Formatting Your SOP

1. 1Choose your format. There is no right or wrong way to write an SOP. However, your company probably has a number of SOPs you can refer to for formatting guidelines, outlining how they prefer it done. If that’s the case, use the pre-existing SOPs as a template. If not, you have a few options:
• A simple steps format. This is for routine procedures that are short, have few possible outcomes, and are fairly to the point. Apart from the necessary documentation and safety guidelines, it’s really just a bullet list of simple sentences telling the reader what to do.
• A hierarchical steps format. This is usually for long procedures — ones with more than ten steps, involving a few decisions to make, clarification and terminology. This is usually a list of main steps all with substeps in a very particular order.
• A flowchart format. If the procedure is more like a map with an almost infinite number of possible outcomes, a flowchart may be your best bet. This is the format you should opt for when results aren’t always predictable.    
2. Consider your audience. There are three main factors to take into account before writing your SOP:
   • Your audience’s prior knowledge. Are they familiar with your organization and its procedures? Do they know the terminology? Your language needs to match the knowledge and investment of the reader.
   • Your audience’s language abilities. Is there any chance people who don’t speak your language will be “reading” your SOP? If this is an issue, it’s a good idea to include lots of annotated pictures and diagrams.
   • The size of your audience. If multiple people at once are reading your SOP (those in different roles), you should format the document more like a conversation in a play: user 1 completes an action, followed by user 2, and so on and so forth. That way, each reader can see how he or she is an integral cog in the well-oiled machine.
   • 
     
3. 3
   Consider your knowledge. What it boils down to is this: Are you the best person to be writing this? Do you know what the process entails? How it could go wrong? How to make it safe? If not, you may be better off handing it over to someone else. A poorly-written — or, what’s more, inaccurate — SOP will not only reduce productivity and lead to organizational failures, but it can also be unsafe and have adverse impacts on anything from your team to the environment. In short, it’s not a risk you should take.
   
   
• If this is a project you’ve been assigned that you feel compelled (or obligated) to complete, don’t shy away from asking those who complete the procedure on a daily basis for help. Conducting interviews is a normal part of any SOP-creating process.
4. 4
   Decide between a short or long-form SOP. If you’re writing or updating an SOP for a group of individuals that are familiar with protocol, terminology, etc., and just would benefit from a short and snappy SOP that’s more like a checklist, you could just write it in short-form.
   • Apart from basic purpose and relevant information (date, author, ID#, etc.), it’s really just a short list of steps. When no details or clarification are needed, this is the way to go.
5. 5
   Keep your SOP’s purpose in mind. What’s obvious is that you have a procedure within your organization that keeps on getting repeated over and over and over. But is there a specific reason why this SOP is particularly useful? Does it need to stress safety? Compliance measures? Is it used for training or on a day-to-day basis? Here are a few reasons why your SOP is necessary to the success of your team:
   • To ensure compliance standards are met
   • To maximize production requirements
   • To ensure the procedure has no adverse impact on environment
   • To ensure safety
   • To ensure everything goes according to schedule
   • To prevent failures in manufacturing
   • To be used as training document
     • If you know what your SOP should emphasize, it’ll be easier to structure your writing around those points. It’s also easier to see just how important your SOP is.

Part 2 of 3: Writing Your SOP

1. 1
   Cover the necessary material. In general, technical SOPs will consist of four elements apart from the procedure itself:
   • Title page. This includes 1) the title of the procedure, 2) an SOP identification number, 3) date of issue or revision, 4) the name of the agency/division/branch the SOP applies to, and 5) the signatures of those who prepared and approved of the SOP. This can be formatted however you like, as long as the information is clear.
   • Table of Contents. This is only necessary if your SOP is quite long, allowing for ease of reference. A simple standard outline is what you’d find here.
   • Quality Assurance/Quality Control. A procedure is not a good procedure if it cannot be checked. Have the necessary materials and details provided so the reader can make sure they’ve obtained the desired results. This may or may not include other documents, like performance evaluation samples.
   • Reference. Be sure to list all cited or significant references. If you reference other SOPs, be sure to attach the necessary information in the appendix.
     • Your organization may have different protocol than this. If there are already preexisting SOPs you can refer to, abandon this structure and adhere to what’s already in place.
2. 2
   For the procedure itself, make sure you cover the following:
   • Scope and applicability. In other words, describe the purpose of the process, its limits, and how it’s used. Include standards, regulatory requirements, roles and responsibilities, and inputs and outputs.
   • Methodology and procedures. The meat of the issue — list all the steps with necessary details, including what equipment needed. Cover sequential procedures and decision factors. Address the “what ifs” and the possible interferences or safety considerations.
   • Clarification of terminology. Identify acronyms, abbreviations, and all phrases that aren’t in common parlance.
   • Health and safety warnings. To be listed in its own section and alongside the steps where it is an issue. Do not gloss over this section.
   • Equipment and supplies. Complete list of what is needed and when, where to find equipment, standards of equipment, etc.
   • Cautions and interferences. Basically, a troubleshooting section. Cover what could go wrong, what to look out for, and what may interfere with the final, ideal product.
     • Give each of these topics their own section (usually denoted by numbers or letters) to keep your SOP from being wordy and confusing and to allow for easy refence.
     • This is by no means an exhaustive list; this is just the tip of the procedural iceberg. Your organization may specify other aspects that require attention.
3. 3
   Make your writing concise and easy to read. Odds are your audience isn’t choosing to read this for fun. You want to keep it short and clear — otherwise their attention will stray or they’ll find the document formidable and hard to grasp. In general, keep your sentences as short as possible.
   • Here’s a bad example: Make sure that you clean out all of the dust from the air shafts before you begin using them.
   • Here’s a good example: Remove all dust from air shafts before use.
   • In general, don’t use “you.” It should be implied. Speak in the active voice and start your sentences with command verbs.
4. 4
   If necessary, interview the personnel involved in the process on how they execute the task. The last thing you want to do is write an SOP that is just plain inaccurate. You’re compromising the safety of your team, their efficacy, their time, and you’re taking an established process and not paying it any mind — something your teammates may find a little offensive. If you need to, ask questions! You want to get this right.
   • Of course, if you don’t know, ask multiple sources, covering all roles and responsibilities. One team member may not follow standard operating procedure or another may only be involved in a portion of the deed.
5. 5
   Break up large chunks of text with diagrams and flowcharts. If you have a step or two that are particularly intimidating, make it easy on your readers with some sort of chart or diagram. It makes it easier to read and gives the mind a brief hiatus from trying to make sense of it all. And it’ll be appear more complete and well-written for you.
   • Don’t include these just to bulk up your SOP; only do this if necessary or if trying to bridge a language gap.
6. 6
   Make sure each page has control document notation. Your SOP is probably one of many SOPS — because of this, hopefully your organization has some type of larger database cataloguing everything within a certain reference system. Your SOP is part of this reference system, and therefore needs some type of code in order to be found. That’s where the notation comes in.
   • Each page should have a short title or ID #, a revision number, date, and “page # of #” in the upper right hand corner (for most formats). You may or may not need a footnote (or have these in the footnote), depending on your organization’s preferences.

Part 3 of 3: Ensuring Success and Accuracy

1. 1
   Test the procedure. If you don’t want to test your procedure, you probably haven’t written it well enough. Have someone with a limited knowledge of the process (or a person representative of the normal reader) use your SOP to guide them. What issues did they run across? If any, address them and make the necessary improvements.
   • It’s best to have a handful of people test your SOP. Different individuals will have different issues, allowing for a wide variety of (hopefully useful) responses
   • Be sure to test the procedure on someone who’s never done it before. Anyone with prior knowledge will be relying on their knowledge to get them through and not your work, thus defeating the purpose.
2. 2
   Have the SOP reviewed by those who actually do the procedure. At the end of the day, it doesn’t really matter what your bosses think of the SOP. It’s those whoactually do the work that it matters to. So before you submit your work to the higher ups, show your stuff to those that’ll be doing (or that do) the job. What do they think?
   • Allowing them to get involved and feel like they’re part of the process will make them more likely to accept this SOP you’re working on. And they’ll inevitably have some great ideas!
3. 3
   Have the SOP reviewed by your advisors and the Quality Assurance team.Once the team gives you the go ahead, send it to your advisors. They’ll probably have less input on the actual content itself, but they’ll let you know if it meets formatting requirements, if there’s anything you missed, and the protocol for making it all official and inputted into the system.
   • Route the SOP for approvals using document management systems to ensure audit trails of the approvals. This will vary from organization to organization. Basically, you want everything to meet guidelines and regulations.
   • Signatures will be necessary and most organizations nowadays have no problem accepting electronic signatures.
4. 4
   Once approved, start implementing your SOP. This may involve executing a formal training for the affect personnel (e.g. classroom training, computer-based training, etc.) or it may mean your paper is hung up in the bathroom. Whatever it is, get your work out there! You worked for it. Time for recognition!
   • Be sure your SOP remains current. If it ever gets outdated, update it, get the updates reapproved and documented, and redistribute the SOP as necessary. Your team’s safety, productivity, and success matter on it.

Read More»

CTMS Procurement: The Seven Deadly Sins

Malcolm Weaver

Keywords: Clinical Trial Management System (CTMS)

Clinical trials are becoming larger, more expensive and increasingly complex. Numerous factors conspire to drive this increase in size, cost and complexity including increased regulatory scrutiny; submissions in greater numbers of markets; a greater proportion of investigational drugs targeted at chronic diseases; and, in some therapeutic areas at least, competition for patients and investigators. Effective management of clinical trials is, therefore, critical for pharmaceutical and biotechnology companies worldwide. In response, vendors have produced a number of IT solutions allowing sponsors, Clinical Research Organisations (CROs) and investigators to run clinical trials more effectively and efficiently. Many clinical trials now employ clinical data management systems (CDMS), clinical trial management systems (CTMS), electronic data capture (EDC), drug supply management (DSM), and interactive voice response systems (IVRS).

CTMS, for example, helps improve trial management processes and better manage costs. Cost management is a particular priority for pharmaceutical and biotechnology companies aiming to maximise their return on investment or minimise the financial burn. It is estimated that keeping a trial running costs around US$40,000 per day. The impact on lost sales revenue is even more marked: every extra day that a drug remains in clinical studies costs the sponsor at least US$600,000 in lost sales. Apart from making it easier for sponsors to attain key clinical trial milestones and helping to control costs, CTMS also offers intangible benefits, such as improved regulatory compliance, reduced complexity, superior information flow and enhanced relationships with clinical investigators.
Several CTMS solutions are available commercially, and the most appropriate choice depends on numerous internal and external factors, many of which are company-specific. However, the author has identified seven ‘deadly procurement sins’ surrounding CTMS. Executives that fail to consider these issues could find that the CTMS does not meet their needs and does not optimise the benefits that the technology could offer their organisation. This article will begin, however, by briefly considering the benefits of CTMS.

The benefits of CTMS
CTMS offers the opportunity to track, measure and report on virtually every aspect of a clinical trial or study program. The relational database at the heart of the CTMS groups, analyses and filters information at various levels including, among others, trial, country, site, investigator, product, clinical research associate (CRA) etc. As a result, a CTMS provides a view of trial management data suited to a variety of individuals within the organisation, including high-level, consolidated metrics for senior managers. The CTMS allows managers to view the progress of several studies and compare approaches in order to optimise future studies. Financial managers can view the total costs and expenditures across clinical programs. The CTMS can also provide detailed reports allowing, for example, a project manager to view enrolment figures for a specific site or investigator and assess the performance of the study recruitment strategy to respond in a timely manner by opening new study sites or taking other actions to ensure target timelines can be met.
Against this background, the CTMS offers five main benefits:
l Companies can track and obtain reports on every aspect of day-to-day trial management. This enhances operational and project management control. Moreover, the CTMS allows managers to deploy monitoring resources in the most appropriate manner to address a particular issue.
l The CTMS delivers relevant information to study stakeholders as rapidly as possible. This helps to manage the relationship between CRO and sponsor as well as enhancing operational control of individual studies and the entire program.
l The CTMS helps sponsors promote operational and workflow standards. CTMS standardises processes across all project teams and increases efficiency, by sharing common data across clinical studies.
l The CTMS can ensure timely investigator payments and allow accurate financial reporting. Timely payments help maintain investigators’ interest in and commitment to the study.
l The CTMS should import data from and export data to other key technologies, such as IVR, EDC and CDMS solutions. Once again, this helps reduce the risk of data entry errors and facilitates the timely completion of the clinical study.
Most vendors offer configuration and customisation options to allow a company to configure a CTMS to meet its specific needs. Beyond these common attributes, the various CTMS differ in several ways. As a result, to ensure that investment in a CTMS is maximised, executives with procurement responsibilities should avoid these seven ‘deadly sins’.
Deadly sin #1: Using old technology
It’s a truism that technology dates rapidly. Therefore, to make the most of the functionality and utility offered by a CTMS (as well as to future-proof the system) the interface and relational databases need to be up-to-date and employ new technologies. Despite this, some CTMS still use technology introduced some 15 years ago. This use of older technology can lead to several problems:
l Installing CTMS based on older technology can be protracted. It can take three days just to load the program from CD-ROMs to the database server.
l Relatively few people have the experience to program and trouble-shoot older software systems. This may be a particular issue in smaller companies.
l Many Windows-based techniques that we use almost instinctively, such as the right mouse click, are not available with the older systems. Using newer systems, users can navigate rapidly, promoting consistent and efficient work processes. An increasing number of studies are performed in non-traditional countries, such as Central and Eastern Europe, Asia and Latin America. Web-based systems, such as TrialWorks® by ClinPhone, IMPACT™, and globalTRIALS™ have a distinct advantage in these studies. The program does not need installation on the user’s PC, which can give substantial savings in terms of PC support. Moreover, web-based systems allow the instant implementation of software updates.
Deadly sin #2: Protracted implementation
Some CTMS applications can be slow to implement. As mentioned above, systems based on older software can take three days to load the program from CD-ROM to the database server. For newer solutions, installation typically takes place in a matter of days. Further, the easy-to-use user interface of modern CTMS, means that clients can begin using these solutions within a few days of installation. With trials often costing tens of thousands of dollars a day, getting the system up and running rapidly is a commercial priority.
Deadly sin #3: Insufficient reporting capability
The ability to access a diverse range of reports tailored to the specific needs of multiple users is the raison d’être for a CTMS. Therefore, the CTMS should offer a vast suite of standard reports, as well as ad hoc reporting, enabling users to quickly access the consolidated information they require. Using systems based on older technology, writing a report can take a day, compared to minutes with newer systems.
Deadly sin #4: No remote monitoring module
Remote monitoring modules offer a valuable tool for mobile CRAs. Before a site visit, the CRA downloads the relevant data they need onto their laptops. During the site visit, the CRA updates the data in the remote monitoring module; this data is then used to create monitoring visit reports and other documentation, and is uploaded to the central database where it is available to other CTMS users. Using a remote monitoring tool is more efficient than employing paper-based systems and, in particular, reduces the risk of errors. This optimises the use of CRA time. Remote monitoring tools are especially valuable when the sponsor uses multiple CROs. The standardised system avoids complications that can arise from different CROs using different management software.
Deadly sin #5: Not working with other key technologies
The CTMS should work with the other IT solutions that are now commonplace in clinical trials. For example, IVR is widely used for randomisation, management of trial supplies and collection of patient diaries. The CTMS should offer two-way, real-time integration with IVR. In this way, for example, the IVRS automatically enters patient enrollment and visit information into the CTMS, providing an accurate and continually updated picture of patient recruitment and progress within the CTMS. Indeed, the CTMS should be able to import relevant information from virtually any IVR, EDC or data management system. This increases the currency of essential tracking and performance data contained within the CTMS, facilitating timely management reports and decisions.
Procurement executives should consider the benefits of being able to export data to Microsoft Word, Outlook, Project, Excel and email/calendaring software, as well as other productivity tools, such as FedEx shipping software. They should also consider including the abilities to hyperlink to study templates, documents and folders; to create XML files for upload to www.clinicaltrials.gov; and to automatically generate check requests. Finally, integrating patient visits with payment data to ensure investigator payment is generated quickly. Rapid payments help establish a good relationships with investigators and their sites.
Deadly sin #6: No hosted solution
Many CTMS companies do not offer a hosted solution. Unfortunately, many smaller clients cannot call on the large IT infrastructure common in larger companies. In other cases, larger companies prefer to outsource IT support in order to focus on their core competencies. As a result, procurement executives need to consider the benefits of licensing and installing the CTMS on-site compared to implementing a hosted solution. In hosted solutions, third-party companies act as an IT department and provide unlimited technical support. The software resides at the host’s facilities, which users access over the internet. The hosting environments are secure and include 24/7 network engineering support, redundant power supplies, redundant internet connectivity and scheduled backups.

Deadly sin #7: Hidden costs
In some ways, the system’s price is the least important of the seven deadly sins. The cost itself is probably less important than the value it represents. Prices for a CTMS can vary from $50,000 to several million dollars. There is often the perception that the higher the price, the better the product. However, in the case of modern CTMS solutions, the very features that make them easy to use and rapid to implement, also lend themselves to rapid development lifecycles, and hence lower license costs.
Executives also need to consider the license structure. Many solutions only offer licenses based on named users, which is inflexible in the current model of clinical research, where companies frequently redeploy resources to maximise efficiency and the use of CROs is prevalent. By comparison, the concurrent user licence model gives companies complete flexibility in how to deploy internal resources and use external ones.
Moreover, using a system with an intuitive and user-friendly interface minimises user training, increases user efficiency and requires less user support. Intuitive systems also facilitate use by third parties or infrequent users with minimal training. These factors all contribute to reducing the overall cost of implementation and ongoing support for the lifetime of the product.
In conclusion, a CTMS makes managing clinical trials easier, faster and more efficient. The choice of vendor and system depends on balancing various and sometimes competing factors. Nevertheless, considering the seven potentially deadly sins outlined above allows companies to procure the most cost-effective and efficient CTMS to meet their needs, maximises the return on investment and helps get the company’s drugs to market as rapidly as possible.

---

((Malcolm Weaver (info@clinicaltrialsoftware.com) is Business Development Manager, ClinPhone Group Limited. To comment on this article, email comment@crfocus.org. Comments might be published on the Clinical Research focus web pages, with author’s name/affiliation, unless notified otherwise)).

Read More»